The present invention relates generally to systems and methods for processing requests for access to data in environments having one or more clients connected to a host (or set of hosts). is Today's computer environment is dominated by "client/server" computer systems. Such a system typically comprises one or more "client" computers connected to a host or "server" computer through a network. An increasingly important application of client/server systems is for providing an Interactive Television (ITV) environment.
ITV environments are typified by set top boxes, at individual customer sites (e.g., consumer home), connected via a broadband network to a central office. Such an environment is illustrated in FIG. 1 as Interactive Television (ITV) environment 100. The environment 100 includes a multitude of set top boxes (STBs) 110, such as set top box 101, connected via a high-bandwidth communication medium 120 (e.g., coax, fiber optic, and the like) to a central office 130. Each set top box itself is generally a small, economically-produced consumer unit which sets atop a television. Communication between the set top box and the central office is bidirectional. In general operation, the set top box 101 interacts with a television, such as television 103.
Through the set top box 101, the central office 130 can send streams of objects to customers, all upon specific requests by the customers. The term "objects," as used herein, encompasses not only classical "objects" with computational capability (e.g., C++objects) but also non-computational objects, including data objects comprising video, pictures, audio, text, and other information. At the central office, one or more server computers (e.g., server 131) are employed for servicing the requests of each particular set top box. In particular, the servers "serve" information to the set top boxes, including information about the kind of services and features (e.g., videos) that the customer or user can receive on his or her TV. Services which the user might receive include, for instance, a travel service, a weather service, a home shopping service, a video rental service, and the like.
The set top box itself is a microcomputer in its own right and, thus, includes common microcomputer components, such as a microprocessor (e.g., Intel 486) and memory (e.g., random-access memory or "RAM"). Since set top boxes are generally geared to the mass consumer market, they must be produced economically. Accordingly, memory in such boxes is typically constrained, relative to what one would find in a desktop computer. Since these clients have a small amount of memory, a problem exist as to how one optimizes the use of local memory: specifically, what objects are brought into local memory and what objects are tossed out of local memory (e.g., during low memory conditions).
In the ITV environment, the time for a server to initially process a request for data is expensive. In other words, the operation of "telling" the server that an object is required is in itself an expensive operation. The "sending" operation, in contrast, is relatively cheap. For systems connected to the Internet, on the other hand, networks tend to have low latency and low bandwidth. In both cases, a problem remains as to how one improves object accessibility and management in the face of slow and/or delayed object transmission.
Classic memory "paging" systems found in standard computer architecture are not well-equiped to address this problem. In ITV systems, typically an ATM (Asynchronous Transfer Mechanism) is employed from the server to the client, thus yielding high bandwidth. The slow or delayed transmission time can be attributed, in part, to the architecture of phone switching networks. In communication from the client to the server, typically a single channel is employed, which must be arbitrated among multiple clients. Since only a fraction of its bandwidth is available to a particular client, it operates much slower.
For instance, to load an application from an Internet server might require that a relatively large portion of the application be transmitted to the local client which then must load particular bits of the transmitted application into its core memory for execution. The latency for performing this task is typically on the order of several seconds, or even minutes. When clients with small memory (e.g., the abovementioned set top boxes) are connected to such networks, the problem is expectedly compounded. The result is a high penalty for I/O (input/output) operations. Coupled with this problem is the fact that typically very little "room" (i.e., memory) exists on the client side for storing objects once they have been received.
Classically, the management of memory resources or "memory management" has been provided at the physical or hardware level. Employing a "paging scheme," prior art systems process memory in terms of "pages," for instance, loading up or swapping out a particular fixed-size physical unit (e.g., 2K page). The approach is ill-suited for the ITV environment, however. Consider an Interactive TV application program. Here, the program developer is more concerned with actual "objects," not physical pages. For example, the developer is concerned about which images are now required to be in memory, which multimedia objects need to be in memory, or which class definitions need to be in memory. To such a developer, physical units, such as 2K memory pages, are not helpful for managing his or her program. Quite simply, the ITV developer cannot practically organize his or her application in terms of physical units, such as memory pages or disk sectors.
Another difficulty with present day paging systems is that of thrashing. Thrashing occurs when the system must repeatedly access the storage device. This results because the act of loading particular pages may lead to the paging out of other pages which, in turn, are required by the pages which are being brought in. Eventually, a working set will quiesce. In a highly dynamic environment, such as in Interactive TV, it is far more difficult ahead of time to predict appropriate working sets for user tasks, as the user has a multitude of execution paths available (e.g., skipping from one page to another in an interactive application). In such an environment, the working set is so dynamic that it will generally not "settle down."
One attempt to solving the foregoing problem to bring together needed functionality is a "Dynamic Link Library" (DLL), such as found in Microsoft Windows and IBM OS/2. Here, particular functionality can be deployed in a single DLL, which is then loaded dynamically at runtime upon request from a client. However, the granularity for DLLs is at the level of the library, not at the level of the object. In other words, when a request is made for particular functionality in a DLL, the system will attempt to load the entire DLL (and its dependents). Once loaded, the DLL will participate in paging in a manner similar to that done for program code in other prior art systems.
"Packaging" is a slight improvement to the approach of Dynamic Link Libraries. In prior art Lisp systems, for example, the developer could specify that a program required a certain "package"--a logical bundling of functionality. To the extent that the developer or programmer can specify dependencies of various packages, the approach is an improvement over Dynamic Link Libraries. Once particular packages are brought in, however, their participation in paging is essentially no different than other regions of physical memory. The packages would be paged in or swapped out according to a standard paging scheme, such as least-recently used (LRU) "aging."
Whether Dynamic Link Libraries or "packages," prior art systems assume a locality of reference (i.e., a grouping together of related items). Multimedia material--images, real time video, and audio--typically violate the locality of reference assumptions and usage patterns employed by traditional paging systems. What is needed, therefore, are systems with methods which provide objects to clients on a per-object basis, not a per-page basis. Further, such a system should respond to user requirements on-the-fly--at runtime--for providing a set of objects in client memory which is meaningful for the user task at hand. The present invention fulfills this and other needs.